Computer-based system for applying machine learning models to healthcare related data

ABSTRACT

Techniques for responding to a healthcare inquiry from a user are disclosed. In one particular embodiment, the techniques may be realized as a method for responding to a healthcare inquiry from a user, according to a set of instructions stored on a memory of a computing device and executed by a processor of the computing device, the method comprising the steps of: classifying an intent of the user based on the healthcare inquiry; instantiating a conversational engine based on the intent; eliciting, by the conversational engine, information from the user; and presenting one or more medical recommendations to the user based at least in part on the information.

FIELD OF THE DISCLOSURE

The present disclosure relates generally to medical decision supportsystems and, more particularly, to systems and methods for responding tohealthcare inquiries.

BACKGROUND OF THE DISCLOSURE

Medical decision support systems have been studied and developed overthe years. See e.g., Miller, Randolph A., “Computer-Assisted DiagnosticDecision Support: History, Challenges, and Possible Paths Forward,”Advances in Health Sciences Education, vol. 14, no. S1 (September 2009):89-106. While there have been different approaches to designing medicaldecision support systems, the most successful ones fall in a categoryknown as expert rule-based systems. Expert rule-based systems involvedomain experts (e.g., case physicians) encoding medical knowledge intorules that are then executed to come up with a decision or arecommendation for a given case. The decision is provided as a rankedlist of diagnosis, also called “differential diagnosis.” Most expertrule-based systems encode knowledge as a bipartite graph with nodesrepresenting findings and diagnoses, and the edges representinglikelihoods of a finding given a diagnosis and/or a diagnosis given afinding.

Two well-known expert rule-based systems are Internist-1 (see e.g.,Miller, R. A., H. E. Pople, and J. D. Myers, “Internist-1, anExperimental Computer-Based Diagnostic Consultant for General InternalMedicine,” The New England Journal of Medicine, vol. 307, no. 8 (Aug.19, 1982): 468-76) and DXplain® (see e.g., Barnett, G. Octo, James J.Cimino, Jon A. Hupp, and Edward P. Hoffer, “DXplain: An EvolvingDiagnostic Decision-Support System,” JAMA, vol. 258, no. 1 (Jul. 3,1987): 67-74). Internist-1 and DXplain® are related to QMR (see e.g.,Miller, R. A H. E. Pople, and J. D. Myers, “Internist-1, an ExperimentalComputer-Based Diagnostic Consultant for General Internal Medicine,” TheNew England Journal of Medicine, vol. 307, no. 8 (Aug. 19, 1982):468-76) since Internist-1 is a precursor and DXplain® is a recentevolution. In both of Internist-1 and DXplain®, the relation between afinding and a disease is encoded into two numbers: “Evoking Strength”encodes the likelihood of a disease given a finding while “Frequency”describes how likely a symptom is to occur given a diseasemanifestation.

Expert rule-based systems such as the ones described above have beenused to support doctors in their medical practice. However, simplifiedversions have also been instantiated as patient-facing applications thatare sometimes called “symptom checkers.” These patient systems haveunreliable accuracy (see e.g., Semigran, Hannah L., David M. Levine,Shantanu Nundy, and Ateev Mehrotra, “Comparison of Physician andComputer Diagnostic Accuracy,” JAMA Internal Medicine, vol. 176, no. 12(Dec. 1, 2016): 1860-61) and have limited features.

Furthermore, creating a new disease in an expert rule-based system isvery costly, both in terms of time and robustness. It may take weeks ofseveral expert diagnosticians working full-time, and the resultingsystem can be brittle and inflexible since it cannot react to newlyavailable data or evidence (e.g., a new disease).

Because of some of these shortcomings, there have been through the yearsmany attempts to develop machine-learned diagnosis models. These includeearly approaches using Bayesian Networks (see e.g., Shwe, Michael A.,Blackford Middleton, D. E. Heckerman, Max Henrion, E. J. Horvitz, H. P.Lehmann, and G. F. Cooper, “Probabilistic Diagnosis Using aReformulation of the INTERNIST-1/QMR Knowledge Base,” Methods ofInformation in Medicine, vol. 30, no. 4 (1991): 241-255) to the mostrecent ones using Deep Learning models (see e.g., Rajkomar, Alvin, EyalOren, Kai Chen, Andrew M. Dai, Nissan Hajaj, Peter J. Liu, Xiaobing Liu,et al., “Scalable and Accurate Deep Learning for Electronic HealthRecords,” ArXiv:1801.07860[Cs], Jan. 24, 2018; Miotto, Riccardo, Li Li,Brian A. Kidd, and Joel T. Dudley, “Deep Patient: An UnsupervisedRepresentation to Predict the Future of Patients from the ElectronicHealth Records,” Scientific Reports, vol. 6 (May 17, 2016)). Thesemachine-learned approaches have been mostly academic research exercisesthat have not been included in commercially-available systems. Also, oneof the reasons for the lack of practical applicability of themachine-learned models is that a medical decision support system notonly needs to have a model that predicts a diagnosis given a set ofinputs, but also needs to provide an efficient way to navigate the pathtowards an optimal diagnosis by asking the right questions. That iseasier to implement in rule-based systems, but gets more complicated formore complex diagnosis models.

More generally, these existing technologies have many shortcomings thatmake them less useful in a patient-facing application. Some relate tothe user interface and experience or the lack of key features, whileothers relate more to the performance or accuracy of the system itself.

In view of the foregoing, it may be understood that there may besignificant problems and shortcomings associated with current medicaldecision support systems. Accordingly, there is a need for addressingthese shortcomings and introducing a whole suite of innovations thatmake it possible to implement a patient-facing medical decision supportsystem.

SUMMARY OF THE DISCLOSURE

Techniques for responding to a healthcare inquiry from a user aredisclosed. In one particular embodiment, the techniques may be realizedas a method for responding to a healthcare inquiry from a user,according to a set of instructions stored on a memory of a computingdevice and executed by a processor of the computing device, the methodcomprising the steps of: classifying an intent of the user based on thehealthcare inquiry; instantiating a conversational engine based on theintent; eliciting, by the conversational engine, information from theuser; and presenting one or more medical recommendations to the userbased at least in part on the information.

In accordance with other aspects of this particular embodiment, theeliciting step comprises using, by the conversation engine, an entropyminimization process to determine a next question to present to theuser, such that subsequent information provided by the user in responseto the next question minimizes the number of medical recommendations.

In accordance with further aspects of this particular embodiment, theentropy minimization process is weighted to optimize diagnosis thatidentifies worst outcomes for early medical intervention on the user.

In accordance with additional aspects of this particular embodiment, theentropy minimization process is weighted to optimize diagnosis fortreating the user's symptoms or disease clusters that maximizes adiagnostic value of the user's response to the proposed treatments.

In accordance with other aspects of this particular embodiment, thepresenting step comprises invoking a knowledge base and a diagnosisengine.

In accordance with further aspects of this particular embodiment, theknowledge base represents normalized medical concepts, which include atleast one of: entities representing findings, symptoms, and conditions;modifiers representing anatomical location, severity, and temporalmodifiers; weighted relations between the entities; relations betweenthe entities and the modifiers; a representation of models and enginesas an instance of a graph with the entities and the relations; a mappingof a medical text to a knowledge base representation by using an entityrecognition module; and additional knowledge sources.

In accordance with additional aspects of this particular embodiment, theentity recognition component module is configured to translatehealth-related text into medical entities and modifiers.

In accordance with other aspects of this particular embodiment, thediagnosis engine is at least one of: a first diagnosis engine based onrules in a knowledge based codifying probabilistic relationships betweensymptoms/findings and diseases; a second diagnosis engine based on firstmachine-learned models deriving relations between symptoms/findings anddiseases from historical medical records; a third diagnosis engine basedon second machine-learned models deriving both probabilities andrelationships from historic medical records; and a fourth diagnosisengine based on third machine-learned models learned from mixed datathat includes at least one of synthetic data generated by a pre-existingexpert system, electronic medical records, manual cases, labelled casesfrom the diagnosis engine.

In accordance with further aspects of this particular embodiment, thehistorical records are either obtained from anonymized databases orgenerated by interactions with the user in a recursive manner.

In accordance with additional aspects of this particular embodiment, thefirst, second, third, and fourth diagnosis engines act in ensemble; eachof the first, second, third, and fourth diagnosis engines operates upona current state of knowledge independently, and offers possibleresponses along with a confidence and value estimate; and an ensemblearbitrator chooses a response out of the possible responses or acollection of responses that is best for the user or circumstance givena match or a mismatch between the possible responses, and a value andconfidence each of the first, second, third, and fourth diagnosisengines expresses in its corresponding response. The ensemble arbitratorlearns a weight to use for each possible response from each of thefirst, second, third, and fourth diagnosis engines based upon history.

In accordance with other aspects of this particular embodiment, theeliciting step includes invoking natural language understanding engine.

In accordance with further aspects of this particular embodiment, theinformation from the user is in the form of at least one of text,speech, imagery, sound, and medical test results.

In accordance with additional aspects of this particular embodiment, theinformation from the user includes at least one of user's medicalhistory and the user's symptoms.

In accordance with other aspects of this particular embodiment, theconversation engine is one of a diagnosis conversational engine, aninformation conversational engine, a referral conversational engine, anda treatment conversational engine.

In accordance with other aspects of this particular embodiment, themethod further comprises, prior to presenting the one or more medicalrecommendations to the user, seeking approval or revision of the one ormore medical recommendations by a medical expert.

In another particular embodiment, the techniques may be realized as asystem for responding to a healthcare inquiry from a user, the systemcomprising: memory for storing instructions; and a processor configuredto execute the instructions to: classify an intent of the user based onthe healthcare inquiry; instantiate a conversational engine based on theintent; elicit, by the conversational engine, information from the user;and present one or more medical recommendations to the user based atleast in part on the information.

The present disclosure will now be described in more detail withreference to particular embodiments thereof as shown in the accompanyingdrawings. While the present disclosure is described below with referenceto particular embodiments, it should be understood that the presentdisclosure is not limited thereto. Those of ordinary skill in the arthaving access to the teachings herein will recognize additionalimplementations, modifications, and embodiments, as well as other fieldsof use, which are within the scope of the present disclosure asdescribed herein, and with respect to which the present disclosure maybe of significant utility.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to facilitate a fuller understanding of the present disclosure,reference is now made to the accompanying drawings, in which likeelements are referenced with like numerals. These drawings should not beconstrued as limiting the present disclosure, but are intended to beillustrative only.

FIG. 1 illustrates a medical decision support system in accordance withan embodiment of the present disclosure.

FIG. 2 illustrates interactions between a medical decision supportsystem and patients and medical experts in accordance with an embodimentof the present disclosure.

FIG. 3 illustrates interactions between a medical decision supportsystem and patients and medical experts in accordance with an embodimentof the present disclosure.

FIG. 4 illustrates an infrastructure of a medical decision supportsystem in accordance with an embodiment of the present disclosure.

FIG. 5 illustrates an exemplary architecture a backend server for amedical decision support system in accordance with an embodiment of thepresent disclosure.

FIG. 6 is a flowchart illustrating a method for responding to ahealthcare inquiry from a user using a medical decision support systemin accordance with an embodiment of the present disclosure.

FIG. 7 illustrates the operation of an intent classification modulewithin a conversational engine in accordance with an embodiment of thepresent disclosure.

FIG. 8 illustrates a structure of a specialized conversational engine inaccordance with an embodiment of the present disclosure.

FIG. 9 is a flowchart for an exemplary entity recognition algorithm thatmay be employed by a natural language understanding module in aspecialized conversation engine in accordance with an embodiment of thepresent disclosure.

FIG. 10 shows an example of an entity extraction in accordance with anembodiment of the present disclosure.

FIG. 11 shows an example of an autocomplete operation in accordance withan embodiment of the present disclosure.

FIG. 12 is a flowchart illustrating a method of training amachine-learned model for a diagnosis engine in accordance with anembodiment of the present disclosure.

FIG. 13 shows a possible diagnosis output from a medical decision systemresulting from symptoms entered by a user in accordance with anembodiment of the present disclosure.

FIG. 14 is a flowchart illustrating a method for responding to ahealthcare inquiry from a user using a medical decision support systemin accordance with an embodiment of the present disclosure.

FIG. 15 illustrates an architecture of a medical decision support systemin accordance with an embodiment of the present disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS

FIG. 1 illustrates a medical decision support system 100 in accordancewith an embodiment of the present disclosure. The system 100 mayinterface with a user (e.g., a patient, a medical expert, etc.) via theuser interface 102. The user may access the user interface 102 throughat least one of a plurality of user devices 101, which may comprise alaptop, a smartphone, a tablet, smart speakers (e.g., Amazon Echo,Google Home, etc.), digital assistants, etc. The user interface 102 maybe in communication with the system 100 backend, which may comprise auser information module 108, a conversational engine 114, a differentialdiagnosis engine (DDx) 116, a knowledge base (KB) 118, and adata/knowledge input module 120.

The user interface 102 may be divided into a user input interface 104and a user output interface 106. The user input interface 104 may allowinput from the user in different modalities, including, but not limitedto, natural language (of the user), speech data (e.g., from a smartspeaker), image/video, and audio. The user input interface 104 mayintegrate the different modalities into a multimodal representation tobe processed by the conversational engine 114, as described below. Theuser output interface 106 may provide the user (i.e., a patient or amedical expert), on at least one of a plurality of user devices 101,with one or more actionable recommendations, such as triaging,diagnosis, treatment, or explanations, as described below. Sometimes,the user output interface 106 may also need to present the user withquestions in order to elicit additional and the right kind ofinformation such that the system 100 is able provide a confidentrecommendation.

The user information module 108 may include two submodules a userprofile/modeling submodule 110 and a personalization submodule 112. Theuser profile/modeling submodule 110 may create and/or update a user'sprofile with all relevant information available about the user from theuser input interface 104. The user profile/modeling submodule 110 may bebuilt on the notion of creating a personalized health record. Thepersonalization submodule 112 may use the user's profile from the userprofile/modeling submodule 110 in order to optimize the relevance of therecommendations and information that the system 100 is to present to theuser.

The conversational engine 114 may be in charge of understanding user'sinput(s), reasoning about the user's input(s), and deciding what is themost appropriate output(s) after consulting with the DDx 116 and the KB118. The DDx 116 may produce a ranked list of possible diagnoses givenany number of findings, which may be symptoms expressed by the patientas well as their history, demographics, etc. In an embodiment, the DDx116 may be based on rules in a knowledge based codifying probabilisticrelationships between symptoms/findings and diseases. In anotherembodiment, the DDx 116 may be based on machine-learned models derivingrelations between symptoms/findings and diseases from historical medicalrecords. In yet another embodiment, the DDx 116 may be based onmachine-learned models deriving both probabilities and relationshipsfrom historic medical records. In another embodiment, the DDx 116 may bebased on machine-learned models learned from mixed data that includes atleast one of synthetic data generated by a pre-existing expert system,electronic medical records, manual cases, labeled cases from thediagnosis engine, as will be described below. Alternatively, the DDx 116may comprise all these embodiments working in ensemble such that eachembodiment may operate based on a current state of knowledgeindependently, and offer possible responses along with a confidence anda value estimate. Additionally, there may be an ensemble arbitrator tochoose a response out of the possible responses or a collection ofresponses from the different embodiments, that is best for the user orcircumstance given a match or a mismatch between the possible responses,and the value and the confidence estimate each embodiment expresses inits corresponding response. The ensemble arbitrator may learn a weightto use for each possible response from each of embodiment of the DDx 116based upon history.

The KB 118 may be a graph representation of medical concepts andrelations between the medical concepts, allowing for concepts,modifiers, relations, and hierarchies. The initial set of concepts inthe graph may be derived from the Systematized Nomenclature of MedicineClinical Terms (SNOMED CT) ontology standard, and represented by unifiedmedical language system (UMLS) concept unique identifiers (CUIs).Relations in the graph may be machine-learned from different sources.The KB 118 may represent normalized medical concepts, which include atleast one of: entities representing findings, symptoms, and conditions;modifiers representing anatomical location, severity, and temporalmodifiers; weighted relations between the entities; and relationsbetween the entities and the modifiers. The normalized medical conceptsmay further include a representation of models and engines as aninstance of a graph with the entities and the relations; a mapping of amedical text to a knowledge base representation by using an entityrecognition module; and additional knowledge sources. As will bedescribed below, the entity recognition component module is configuredto translate health-related text into medical entities and modifiers.The KB 118 may grow and may incorporate future concepts as needed. Thefollowing is an example of some concepts and relationships that may berepresented in the KB 118:

 findings:   {    “id”: 31,    “name”: “hip pain”,    “expression”:“22253000|pain:363698007|Finding    site=3049079005|hip”,   }  diseases:  {     “id”: 7,     “name”: “acute renal failure”,     “expression”:“14669001|acute renal, failure”,   } relationships:  “304907005|hip”: [  {     “is_a”: “39352004|joint”   }  } edges:   {    “disease”: 7,   “finding”: 31,    “metadata”: {     “strength”: 0.8284268201196736   }   }

The above exemplary graph illustrates a relationship between a finding31 (“hip pain”) under the “findings” node and a disease 7 (“acute renalfailure”) under the “diseases” node. The relationship is captured underthe “edges” node of the graph with a relative “strength” of 0.83 (i.e.,it is closely related or “common”). Moreover, each node may captureadditional information under the “expression” field. For example, thefinding 31 (“hip pain”) is of type “pain” and is located in the “hip.”Also, under the “relationships” node, “hip” is defined as a “joint”. TheKB 118 may also provide an application programming interface (API) witha set of operations that allow to navigate the graph. A sequence ofexemplary operations may be:

-   -   get_children: joint→[knee, elbow, shoulder, ankle]    -   refine    -   “knee pain”→“severe knee pain”    -   “joint pain”→[“knee pain”, “elbow pain”, “ankle pain”]    -   expansion: “knee swelling”→[“knee pain”, “knee inflammation”,        “knee . . . ”, “hand swelling”, “joint swelling”, “ . . .        swelling”]

In this example, the “refine” operation allows to retrieve entities of aparent node type from the KB 118. For example, when the “refine”operation is applied to “joint,” the KB 118 returns different kinds ofjoints; when applied to “joint pain,” the KB 118 returns different kindsof joint pains; and when applied to “knee pains,” the KB 118 returnsvariations of knee pain. The “expansion” operation does a traversal ofthe graph and returns any valid modification for any of the concepts inthe expression. For example, when the “expansion” operation is appliedto “knee swelling,” the KB 118 returns all possible types of kneeconditions, as well as swellings.

Both the DDx 116 and the KB 118 may be informed by the data/knowledgeinput module 120. The DDx 116 may further be informed by the KB 118. Thedata/knowledge input module 120 may intake different data sources andmodels, such as datasets 130 and rules/protocols 132. Examples of thedatasets 130 are electronic medical records (EMRs) (also known aselectronic health records (EHRs)) and Wikidoc (www.wikidoc.org). Therules/protocols 132 may come from medical experts, from decision supportsystems such as DXplain®, for example. In addition to the datasets 130and the rules/protocols 132, the data/knowledge input module 120 mayalso intake information and data from the user input interface 104.

The data/knowledge input module 120 may include a medical recordsunderstanding submodule 122, an expert systems input submodule 124, amedical text understanding submodule 126, and a model/knowledgeinference submodule 128. The medical records understanding submodule 122may parse and understand medical data in EMRs by applying naturallanguage processing (NLP) technologies to doctors' notes and encodingall other available information as features that may be used in latermodeling stages. The expert systems input submodule 124 may ingestarbitrary knowledge graphs and encode them in a way that may beunderstood and combined with other existing models. The medical textunderstanding submodule 126 may apply NLP technologies to extractconcepts and relations from existing medical text resources to constructknowledge base graphs and diagnosis models.

The model/knowledge inference submodule 128 may be a service model thatincludes functionalities that is needed by the other submodules. Onesuch example of the functionalities may be to allow the medical recordsunderstanding submodule 122, the expert systems input submodule 124,and/or the medical text understanding submodule 126 to interface withthe model combination/reasoning module 134, which informs the DDx 116.The model combination/reasoning module 134 may select the optimal modelneeded for making a particular diagnosis. In an embodiment, modelcombination/reasoning module 134 may respond to rules about which of theexisting models respond better to a kind of diagnosis. For example, amodel that has been trained on medical records from a pediatric hospitalwill be preferred when building a diagnosis for a child. In anotherembodiment, the model combination/reasoning module 134 may be anensemble trained on data such that responses from different models arecombined with different weighs corresponding to the models' abilities torespond to previous similar cases. Another functionality of themodel/knowledge inference submodule 128 may be to interface with theknowledge representation module 136, which informs the KB 118. Theknowledge representation module 136 may use the output of thedata/knowledge input module 120 and organize the output in arepresentation that is usable by the other modules. For instance, theknowledge representation module 136 may provide processed knowledge andstructures from the data/knowledge input module 120 to the KB 118.

FIG. 2 illustrates interactions between a medical decision supportsystem 200 and patients and medical experts in accordance with anembodiment of the present disclosure. The system 200 may be a cloudservice system. The system 200 may encompass the system 100 and enable aplurality of client applications. For example, a patient-facingapplication may be deployed as a web-based application 202, as well as amobile device application 204. The system 200 may include a plurality oftools 206, for example via a computer, providing functionalities formedical experts to access data generated by patients during theirsessions with the system 200.

FIG. 3 illustrates interactions between a medical decision supportsystem 300 and patients and medical experts in accordance with anembodiment of the present disclosure. The system 300 may be a cloudservice system. The system 300 may encompass the system 100 and enable aplurality of client applications. While a patient may interact directlywith a web-based application 302 and/or a mobile device application 304,the cloud service system 300 may also provide the ability to input datafrom medical and health devices 308 (e.g., a heart-rate monitor, anat-home blood pressure device, etc.), as well as results from laboratorytests 310 (e.g., from conventional laboratories, at-home or in-pharmacyinstruments, etc.). The system 300 may include a plurality of tools 306,for example via a computer, providing functionalities for medicalexperts to access data generated by patients during their sessions withthe system 300 and/or to access patient data from the medical and healthdevices 308 and the laboratory tests 310.

FIG. 4 illustrates an infrastructure 400 of a medical decision supportsystem in accordance with an embodiment of the present disclosure. Theinfrastructure 400 may be exposed to users via an application proxy (AppProxy) node 402, which may route requests to an administrativeapplication (Admin App) 404 and/or a client application (Client App)406, while restricting access to other internal resources. The App Proxynode 402 may be a Hypertext Transfer Protocol (HTTP) server, which mayhandle both serving web resources and acting as a proxy between thepublic internet and the Admin App 404 and the Client App 406. An exampleof such an HTTP server is an nginx server. An engine 408 may reside in acloud service system. For example, the engine 408 may be deployed as aPython Flask server running on a cloud service system (e.g., GoogleCloud), while the Admin App 404 and the Client App 406 may share afrontend stack, which may for example be built on React, a JavaScriptlibrary. The infrastructure 400 may be built on top of a Dockercontainer platform. Each of the major components in the infrastructure400 may be packaged and deployed as a self-contained container, avoidingthe need to keep development and production environments insynchronization in terms of tools, dependencies, etc.

The engine 408 may be the backend server for a medical decision supportsystem (e.g., the system 100, 200, or 300), and may provide thefollowing functionalities:

-   -   Functionalities available on the Admin App 404 and the Client        App 406    -   Packaging all supported knowledge bases (e.g., Sontag, VDDX,        Wiki) in the medical decision support system    -   Implementing algorithms that operate on the knowledge bases to        provide functionalities such as next question to be posed to a        patient and diagnosis to be presented to the patient    -   Logging user activity and managing user session history    -   Providing messaging support between patients and medical experts        As shown in FIG. 4 , the engine 408 may be in communication with        a database 410, which in turn may be in communication with a        backup database 412. The database 410 may store all data        transactions including user and doctor information. The backup        database 412 may be a secondary storage where a daily snapshot        of the database 410 may be stored, for example, for security        purposes.

FIG. 5 illustrates an exemplary architecture of the engine 408 inaccordance with an embodiment of the present disclosure. The engine 408may be a Python server built on a Flask server 510. Flask aims to be alightweight, but extensible framework for building Python services andservers. Flask libraries, such as authentication, logging, persistence,HTTP request/response, etc., are available for functions andfunctionalities needed to build the engine 408. The engine 408 may bedeployed, locally and/or on a cloud service system, as a self-containedDocker image, which may be a composition of several smaller Dockerimages with specific functionalities. The engine 408 may include anin-memory knowledge base (KB) 514 that may contain relevant datasetsimported into internal data structures. At runtime, the Flask server 510may perform only read operations on the KB 514. The KB 514 is served asa binary SQLLite file that gets loaded into memory on startup. Theengine 408 may further include a MySQL server 520, which may hostdatabases used by the Flask server 510. In an embodiment, only user data(e.g., patient profiles and their interaction sessions) may be stored inthe MySQL server 520, while the KB 514 is served as a binary file. ACelery 518, which may be included in the engine 408, is an asynchronoustask queue/job queue based on distributed message passing. The Celery518 may be focused on real-time operation, and may also supportsscheduling. The Celery 518 may be used in the engine 4408 to scheduleand execute non-blocking tasks, such as sending messages, therebyallowing the Flask server 510 to respond to users' requests quicklywithout being blocked by slow calls that may be executed asynchronous. ARedis 516, which also may be include in engine 408, is an in-memory datastructure store that may be used as a database, cache, and messagebroker. The engine 408 may schedule asynchronous tasks by writingobjects into the Redis 516, to which the Celery 518 may be continuouslylistening for changes and handling/executing any tasks as they arrive.

FIG. 6 is a flowchart illustrating a method 600 for responding to ahealthcare inquiry from a user (e.g., a patient) using a medicaldecision support system (e.g., the system 100, 200, or 300) inaccordance with an embodiment of the present disclosure. The method 600begins at step 610 with the user making a healthcare inquiry. At step620, the method 600 determines and classifies the intent of user'sinquiry as one of a plurality of intent classifications (as describedbelow), using a conversational engine (e.g., conversational engine 114).The method 600 proceeds to step 630, where a decision is made as towhether the user's intent is understood. If the user's intent is notunderstood (in which case, no trustworthy actionable recommendation maybe provided with some degree of confidence), the user's inquiry isescalated to a doctor, at step 640. However, if the user's intent isunderstood at step 630, the method 600 moves to step 650 andinstantiates one of a plurality of specialized conversational enginesfor the intent, based on the intent classification. Then, at step 660,based on interfacing with a diagnosis engine (e.g., the DDx 116) and aknowledge base (e.g., the KB 118), the method 600 elicits moreinformation from the user (if needed). Once all needed information isobtained from the user, the method 600 decides, at step 680, whether aconfident recommendation may be made. If a confident recommendation maynot be made at step 680, the user's inquiry is escalated to a doctor, atstep 640. Otherwise, a recommendation (e.g., diagnosis, referral,treatment, etc.) is made to the user at step 690. The goal of the method600, therefore, is to provide at least one of a plurality of actionablerecommendations to the user.

A medical decision support system (e.g., the system 100, 200, or 300)typically includes a software system to manage a patient dialog systemto perform one or more of the following steps:

-   -   clarify question that the patient asked    -   gather additional information, including presence or absence of        additional symptoms, patient history, demographic data, etc.    -   establish the patient intent    -   gather such additional details as calendar appointment details,        insurance details, emergency contact information, etc.

The medical decision support systems described herein may be included ina broad category of dialog systems, with a specific focus on medicaltasks. Dialog systems may be generally categorized as task-oriented(e.g., buying a plane ticket) or chatbots. Most approaches to dialogsystems have used a “slot-filling” mechanism, where an initial framewith slots is defined and the goal of the dialog is to fill in thoseslots. See e.g., Jurafsky and Martin, “Speech and Language Processing,”2^(nd) edition. Research into end-to-end dialog systems using DeepLearning techniques has recently emerged. See e.g., Bordes et al.,“Learning End-to-End Goal-Oriented Dialog,” International Conference onLearning Representations, 2016. The systems described herein may use acombination of both approaches with a goal of offering not only anaccurate, but also a natural medical conversation.

A patient dialog system may be comprised of a series of templates forthe information required, and formulations for questions to pose to thepatient to elicit that information. A model may represent the system'scurrent estimate of the patient objectives, and chooses next questionsto be asked with a combination of the following objectives:

-   -   clarifying, quantifying, or modifying a previous response    -   prompting for additional inputs that the patient may consider        important or relevant    -   identifying symptoms that may discriminate between different        possible diagnoses or patient states, and asking whether the        patient is experiencing any such symptoms, from general to        specific (e.g., pain, joint pain, elbow pain, shooting elbow        pain, etc.)    -   asking questions about symptoms that may serve to strengthen or        weaken the hypotheses about specific diseases that may be        present    -   asking for personal health history, including but not limited to        gender, age, ethnicity, previous diseases, vaccinations, current        and past prescriptions, ancestry, and ancestors' health status,        etc.    -   prompting for input of, or connection to existing health or test        records to integrate into the model

In order to offer the above functionalities, the system may implement adialog engine (e.g., the conversational engine 114) that may include anintent classification module. FIG. 7 illustrates the operation of anintent classification module 710 within a conversational engine 700, inaccordance with an embodiment of the present disclosure. Theconversational engine 700 may be an example of the conversational engine114. The intent classification module 710 may classify a user's intentinto a finite set of “intents.” Those intents include, but are notlimited to, diagnosis, doctor referral, prescription or treatmentrecommendation, and information on a given disease. The intentclassification module 710 may be built by using a combination of encodedrules and machine-learned classifier models. Encoded rules help theintent classification module 710 to identify patterns that are thentreated as a single entity. For example, “right lower back” may beidentified as an anatomical part plus two location modifiers. Entitiesand processed raw text (through, e.g., embeddings) may then be fed intoa supervised classification component that has been trained usingthousands of labeled examples. As shown in FIG. 7 , the intentclassification module 710 may then route the user query to one of aplurality specialized conversational engines—information conversationalengine 720, referral conversational engine 730, diagnosis conversationalengine 740, treatment conversational engine 750, other conversationalengine(s) 760—, each configured to handle a classified intent.

Each specialized conversational engine may be built using a combinationof a natural language understanding (NLU) module, an autocompletemodule, and a next question module. For instance, FIG. 8 illustrates thestructure of the diagnosis conversational engine 740 in accordance withan embodiment of the present disclosure. As can be seen in FIG. 8 , thediagnosis conversational engine 740 may include a natural languageunderstanding module 742, an autocomplete module 744, and a nextquestion module 746.

Generally, for each specialized conversational engine, an NLU module mayoperate with unstructured natural language inputted as text, which mayinclude textual representations of other modalities such as voicetransformed into text through a speech-to-text system. In order for theNLU module to understand and decide on next steps, it may apply anentity recognition algorithm that may recognize words and extractrelevant medical concepts including modifiers, quantifiers, andnegations. Entities may be mapped to a knowledge base unique identifier.Therefore, the output of the NLU module is a structured representationof the user query in the form of a combination of identifiers, which maybe interpreted to determine next steps according to rules in each of thespecialized conversational engines.

FIG. 9 is a flowchart for an exemplary entity recognition algorithm 900that may be employed by an NLU module in a specialized conversationalengine in accordance with an embodiment of the present disclosure.

The entity recognition algorithm 900 starts with the text processingstep 902. The text processing step 902 includes information retrieval(IR) processing, which involves removing, from text input by a user,various punctuations and standardization of certain tokens. Unlike instandard IR processing, the text processing step 902 does not removestop words. Stop words tend to function as a bridge to connect entities.Stop words may be removed, if needed, in the pruner step 908, describedbelow.

The entity recognition algorithm 900 then moves to the text synonymizerstep 904. The text synonymizer step 904 is used to generate varioussynonymous ways of representing the processed text from the textprocessing step 902. For example, the text may be split into acollection of overlapping K-grams (K=1 to 10) using a sliding window.The location of each K-gram in the text may be preserved. Each K-gramphrase may be synonymized by lookups on Wordnet, word-by-word. Whenthere are multiple words in the phrase that have synonyms, all possiblecombinations may be maintained, by constructing the combinationsrecursively. Some phrases may not have synonyms, while others may havemany.

Following the text synonymizer step 904 is the annotator step 906, whichis used to identify all entities in the free text. That is, all phrasesand their synonyms are identified. A dictionary data structure may beused for fast lookups. Maintaining K-grams of various lengths and theirlocations in the input text may facilitate the annotator step 906.

Once the annotator step 906 completed, the entity recognition algorithm900 moves the pruner step 908. At the pruner step 908, two operationsare performed. First, entities that are sub-entities of anotheridentified entity are pruned. For example, for the user text “kneepain,” the entity corresponding to “knee” and “pain” are removed, andonly the entity corresponding to “knee pain” is kept. Second, entitiesthat can correspond to stop words such as “in” are pruned.

Next comes the entity merger step 910. The UMLS is not always consistentin concept representation. For example, UMLS may have concept “kneepain,” but not “pain in the knee” as a synonymous. Through analysis on alarge number of extractions, a small number of rules or patterns may becaptured that are effective in capturing the main concepts that are ofinterest. For example, these rules may include the following code:

 <body system> = {“Body Part, Organ, or Organ Component”, “Tissue”,“Body Location or Region”,    “Body Space or Junction”, “Body System”,“Anatomical    Structure”}  <findings> = {“Finding”, “Sign or Symptom”,“Body Substance”, “Disease or Syndrome”}  # <findings>|stop|<bodysystem>  # <body system>|stop|<findings>  # <bodysystem>|stop|Qualitative Concept  # Sign or Symptom|stop|OrganismFunction   # Example: pain|with|urination, pain|with|periods  # BodySystem|stop|Pathologic Function   # Example skin||bleeding|  #Pathologic Function|stop|Body System   # Example |bleeding|into|skin or|bleeding||skin|The Pruner step may be important to increase coverage. The output ofPruner step may be used to identify entities that are in the vicinity ofeach other that satisfies one of these rules, and where stop is stopwords. If so, the entities may be merged and annotated, using theannotator step 906. During the entity merger step 910, the chances formatches are also increased by using the UMLS synonyms of two entities,and taking their cross-product combinations. This may further improveidentification. At the end of the entity merging step 910, the prunerstep 908 may be run again, for further clean up. It is worth notingthat, along this process, the location of the merge in original freetext is maintained.

In the subsequent sundry step 912, when the text is large, redundantentities are removed, based on CUIs of the entities identified. Thereturned list of entities may be restricted to be only those defined asfindings.

Lastly, in the matcher step 914, the output from the sundry step 912 ismatched to engine specific findings, in two ways: (1) exact match on theCUIs between the entities and findings in knowledge base; and (2) when(1) is not present, approximate match based on a number of matching,missing, and mismatching entities between the candidates (withmismatching penalized more than missing).

FIG. 10 shows an example of an entity extraction in accordance with anembodiment of the present disclosure. As can be seen, if the phrase “Iam not feeling great today and my head hurts” is input by a user, anentity recognition algorithm within an NLU module of a specializedconversational engine may return “headache” and “general malaise” aspossible symptoms to the user.

An autocomplete module may allow a specialized conversational engine tosuggest medical concepts or entities coming from the knowledge base(e.g., KB 118) as a letters from a user are being inputted in thesystem. The suggestions not only include words that include the lettersentered by the user, but also words that include the letters among theirsynonyms. FIG. 11 shows an example of an autocomplete operation inaccordance with an embodiment of the present disclosure.

The next question module in a specialized conversational engine may beable to determine the optimal next question to ask a user given thecurrent state of the dialog between the user and the specializedconversational engine. The way that the optimal next question may bedetermined depends on the specifics of each specialized conversationalengine, but it generally may be based on either predetermined frames ora entropy minimization algorithm. As an example of the predetermineframes, the referral conversation engine (see FIG. 7 ) may instantiate aframe with the necessary information (location, preferred time,preferred gender, specialty, etc.) and will determine a next question inorder to fill in the blank slots in this frame. As an example of anentropy minimization next question approach, the diagnosisconversational engine (see FIGS. 7 and 8 ) may initially formulate adifferential diagnosis and determine a next question by minimizing theentropy difference of the existing hypothesis. In other words, the goalis to minimize the entropy of the differentials. Before asking aparticular question, this is given by

${H_{p({d{❘\mathcal{F}^{t}}})}(d)} = {- {\overset{K}{\sum\limits_{k = 1}}{{p\left( {d = {k{❘\mathcal{F}^{t}}}} \right)}\log{p\left( {d = {k{❘\mathcal{F}^{t}}}} \right)}}}}$

where F′ is the collection of the current findings and p(d|F′) is theposterior probability of disease d given the current findings. Once agiven question is asked the entropy can be written as:

(d)=0.5*

(d)+

(d)]

where 0.5 assumes an equal probability of a patient answering positivelyor negatively to a question, but could in fact be a probabilitydistribution. Given this, the goal of the next question algorithm is tofind f* by maximizing the following expression:

$f^{*} = {{\arg\max\limits_{f}{H_{p({d{❘\mathcal{F}^{t}}})}(d)}} - {{\overset{\sim}{p}\left( {f = 1} \right)}{H_{p({d{❘{\mathcal{F}^{t},f}}})}(d)}}}$

In order to understand and reason about medicine, and have meaningfuldialogs/conversations with patients, the system needs to have arepresentation of medical concepts. This involves having a knowledgebase, and tools to convert or translate from any language representationto the internal knowledge graph representation. For example, the NLUmodule described above in a specialized conversational engine needs toconvert natural language into a list of identifiers from the knowledgebase. But, that is also true for natural language generated by doctors,or structured information coming from electronic medical records or anexternal knowledge base.

The language of medicine also includes tools to map text to knowledgebase representation (as described in the NLU module above) and tonavigate a knowledge base graph in different directions (e.g., “findrelated nodes” or “find parent of”).

An important feature of a medical decision support system (e.g., system100, 200, or 300) is a diagnosis engine (e.g., DDx 116). According to anembodiment, a multi-class classifier on co-occurrence of medicalconcepts in EMRs may be extracted. This produces a graph of medicalconcepts and edges between them, where the edge weights model theprobability of co-occurrence of, for example, a disease given a symptom.Given such a graph, a diagnosis algorithm may be devised. Theprobability of a finding being present given a disease may be estimatedas follows:

${p\left( {f_{j} = {1{❘{d = k}}}} \right)} = \left\{ {\begin{matrix}{\alpha_{j,k},} & {{if}{in}{graph}} \\{\beta,} & {otherwise}\end{matrix},{\beta = {\text{.0001} \approx {\text{.01} \times \min_{j,k}\alpha_{j,k}}}}} \right.$

where α_(j,k) are the learned weights and β is a very small number.

Other information, but symptoms, such as patient demographics or diseaseprevalence, may be incorporated, as follows:

p(d,f,age,gender)=p(f|d,age,gender)p(age|d)p(gender|d)p(d)

In order to calculate the posterior probability of the diseases, Bayesrule may be invoked. The compute probability may be used to rank thedifferential diagnosis given the currently available information.

A medical decision support system (e.g., system 100, 200, or 300) mayincorporate several engines working in ensemble. These engines mayinclude rule-based engines, wherein rules in a knowledge base specifythe strength of relationship between a symptom/finding, and diseasesthat may cause such symptoms. Those rule-based systems are derived fromexisting medical literature by using a combination of manual curationfrom expert physicians and statistical techniques.

Additionally, engines that are based on models learned from data may beincluded. Such models quantify the relation between symptoms anddiseases observed in real-world data. The models are trained usingvarious medical data such as anonymized EMRs from research databases oruniversity hospitals, and from introspecting on the data collected infeedback and follow-up from the engine's own interaction with patients.Sources of bias in the samples that drive the models may be quantified,and the models may be corrected for known and estimated bias. The modelsmay incorporate disease and symptom prevalence in the generalpopulation, and may include how those statistics vary in specificsubpopulations by demographic, geography, calendar, social connections,etc. In one embodiment, the models are constrained to quantifyrelationships identified by the rule-based engines. In anotherembodiment, the models are allowed to infer knew relationships that havenever been encoded as an explicit rule.

FIG. 12 illustrates a method 1200 of training a machine-learned modelfor a diagnosis engine in accordance with an embodiment of the presentdisclosure. The method 1200 may start at step 1210 with a rule-basedexpert system. At step 1220, the rule-based expert system is used as agenerative model to create sample medical cases. At step 1240, thesample medical cases created at step 1220 are used to train amachine-learned model. The machine-learned model may then be applied toa medical decision support system at step 1250. This becomes a novel andeffective way to extend and generalize expert systems that can then becombined at the data level. At step 1230, the medical cases generated bythe expert system may be combined with other medical cases such asmanually generated medical cases 1260, medical cases 1270 gathered fromsources such as EMRs, and/or labeled medical cases 1280 from the systemusage itself.

Referring back to FIG. 1 , one important aspect of the system 100 isthat it allows for multimodal input as part of the dialog/conversation.The system 100 allows a user/patient to input voice, images, and videoas part of the dialog flow. For example, if the patient mentions havinga skin rash, the system 100 may invite the patient to upload a picture.The system 100 may then perform automatic image classification and willuse the output as another symptom in the diagnosis. Beyond typicalmultimedia documents, the system 100 may be designed to acceptinformation coming from any medical sensor or monitoring device (e.g.,heart rate monitor, blood pressure monitor, etc.).

Another important feature that the system 100 may provide is a personalhealth record (PHR), which is a longitudinal record of all relevanthealth data from history questions and from previous sessions by anindividual patient, integrated with conventional medical records (EMRs,EHRs) from one or multiple healthcare providers, including bothstructured and unstructured doctors' notes, prescription records, etc.Unlike an EMR, a PHR may always be available to the patient to query,manage, examine, or update. The PHR is not intended to replace thespecific electronic records stored at the health institutions, butrather complement and offer a holistic view of a patient's health thatincludes not only the aggregate of the patient's interactions with theirhealth providers, but also more nuanced interactions with the system100. For example, the PHR in the system 100 may include informationabout interactions where the patient complained or asked about aheadache despite none of those might have resulted in any medicaltreatment. The PHR that may be offered in the system 100 remains theproperty of the patient and enables the patient to not only visualize,but also modify and comment in order to add more detailed or nuancedinformation.

As described before, the goal to the system 100 is to answer patientquestions by giving a set of actionable recommendations that may includenot only a diagnostic and triaging, but also referral or treatment. Oneimportant actionable recommendation that a patient that is looking forinformation about her health situation can get is whether she needs tovisit a doctor and what is the relative urgency of the medicalattention. This is accomplished by the ability of the system 100 totriage patients. In most situations, the triaging decision may beaccomplished by formulating a diagnosis and classifying the diagnosisinto the required attention and urgency. However, in many othersituations, the simple existence of a symptom can trigger a triagerecommendation. For example, chest pain on an elderly patient or highfever in an infant will trigger an automatic recommendation to visit theemergency room regardless of the confidence on the diagnosis.

Many questions from patients may be directly related to them wanting toknow “what they have”. The system 100 may respond in the form of adifferential diagnosis. This includes a ranked list of possibleconditions with an indication on how likely they are and recommendednext steps. FIG. 13 shows a possible diagnosis output from the system100 and the symptoms entered by a user that led to the output inaccordance with an embodiment of the present disclosure.

While the system 100 may be designed to give up-to-date and accuratemedical information, in many situations, the interaction with thepatient will determine that the best path forward is for her to visit adoctor. Exemplary cases when the system 100 may decide to refer thepatient to a doctor may include, but is not limited, to the following:

Probability of complications are above a certain threshold

Patient requires physical examination or lab tests

The internal algorithms are not certain of what is the issue with thepatient

The patient has described a critical symptom (e.g., “chest pain”)

In all these cases, the system 100 may determine the best doctor to whomto refer the patient considering different variables that includeeverything that is known about the patient (e.g., location, healthcareprovider) and their current situation (e.g., vitals, symptoms). Thesystem 100 may present a ranked list of recommendations. The system 100may include a database of doctors and facilities that can provide agiven medical procedure or service. On the other hand, the system 100may also provide the possibility to refer directly to in-housephysicians through text or video consultation.

Given a disease, or cluster of diseases that may afflict a patient, acomponent of the system 100 may be designed to sort through alternativepossible treatments, qualify them based upon relevance to the patient'ssymptoms and history, and propose possible treatments that the patientcould pursue.

In follow-ups, the system 100 may collect data on treatment paths chosenby the patient, and outcomes, and use these data to learn models forwhich treatments to propose to other patients in the future. Some ofthose treatments may involve prescriptions or recommendations forover-the-counter medications. For the former, the system 100 may includereferral to a healthcare professional, who can safely prescribemedications. This could be an offline prescription based on datacollected, a real-time or scheduled chat or message interaction, areal-time or scheduled video consultation, or a scheduled visit forphysical examination. In any of these cases, the system 100 mayfacilitate the paperwork of prescribing and forwarding the prescriptiononto a pharmacy.

The system 100 may include a database of pharmacy within which it can:

-   -   Cross-check against other medications the patient may be taking    -   Validate dosage for the demographics, weight, gender of the        patient    -   Warn about possible side-effects, and incorporate follow-up on        such side-effects in future interactions with the patient.    -   Evaluate responses to prescribed medications to confirm or        reduce weight on previous conclusions about the patient's        disease or condition    -   Guide or advise on substitutions with alternatives or generic        medications that may be differentially available, covered by        insurance, and have differing efficacies.

Similarly, some situations may require the patient to undergo some formof laboratory testing. In some cases, the kind of testing might beavailable through some form of at-home procedure (e.g., blood pressure),but in many other cases the patient may need to visit a physician orpharmacist. For the former, the system 100 may refer the patient toexisting third-party applications and solutions. For the latter, thesystem 100 may refer the patient to nearby facilities considering allthe information about the patient and the current situation (e.g., howurgent the test is). In any of these cases, the system 100 mayfacilitate the paperwork. The system 100 may include a database ofpharmacies and doctors that may provide a given test procedure.

A key to effective machine learning is generating data from which tolearn. The system 100 may be designed for comprehensive follow-up witheach patient, which may take the form of:

-   -   Follow-up questions to the patient asking whether their        situation followed the trajectory that the system projected.    -   Follow-up questions to the patient asking about new, changing,        or past symptoms    -   Follow-up questions to the patient asking whether they followed        up with their doctor, and what the doctor might have confirmed        or changed.    -   Follow-up questions to the any doctor or professional to add        their corrected labels to the record.    -   Checking with other sources of EMR to learn results from        additional testing or procedures prescribed.    -   Independent third-party review of interactions by expert doctors        trained in classifying open-loop data and attaching a correct        label to the outcome.

The system 100 has the goal of offering actionable and personalizedhealthcare information to patients. All use cases outlined above havesome flavor of understanding a patient informational need and presentingsome information about the patient's situation or the next steps totake. In order to serve those informational needs, the system 100 mayinclude comprehensive content that may be indexed and presented inresponse to any question. This includes:

-   -   Information about diseases, symptoms, and treatments    -   Information about medications    -   Information about laboratory tests and other medical procedures    -   Information about doctors and medical facilities, including        their locations and services provided by them        Such content may be structured, tagged, and categorized in the        system 100 so that it may be served in response to concrete        informational needs and personalized in different ways.

FIG. 14 is a flowchart illustrating a method 1400 for responding to ahealthcare inquiry from a user (e.g., a patient) using a medicaldecision support system (e.g., the system 100, 200, or 300) inaccordance with an embodiment of the present disclosure. The method 1400begins at step 1410 with the user making a healthcare inquiry. At step1420, the method 1400 classifies the intent of user's inquiry (e.g.,using intent classification module 710). The method 1400 proceeds tostep 1430, where a decision is made as to whether the user's intent isrelated to either a diagnosis or a treatment. If the user's intent isnot related to either a diagnosis or a treatment, the method 1400invokes a converse at step 1440. The converse generates a reasonableresponse based on what the medical decision support system knows aboutits past few interactions with the user. However, if the user's intentis related to either a diagnosis or a treatment at step 1430, the method1400 moves to step 1450 and determines whether the confidence on a givendiagnosis or treatment is above a predetermined threshold. If theconfidence is below or at the predetermined threshold, the method 1400moves to step 1460 to generate a next question, as described above, toelicit more information from the user. If the confidence is above thepredetermined threshold, the method 1400 moves to step 1470 tocommunicate either a diagnosis or a treatment (informed by a diagnosisengine (e.g., the DDx 116) and a knowledge base (e.g., the KB 118)) tothe user. Any of the response from step 1440, the next question fromstep 1460, and the diagnosis or treatment from step 1470 may require anoptional approval/edit by a medical expert at step 1480 before beingpresented to the user. For example, the method 1400 may trigger step1480 based on predefined settings (e.g., a physician may need to approvediagnosis recommendations that include diagnosis above a certainseverity).

FIG. 15 illustrates an architecture 1500 of a medical decision supportsystem in accordance with an embodiment of the present disclosure. Thearchitecture 1500 may be used to perform the method 1400, for example.As can be seen in FIG. 15 , a dialog manager 1506 may be a centralcomponent in the architecture 1500. The dialog manager 1506 maycommunicate with the patient via a patient user interface (UI) 1502 andwith a medical expert via a medical expert UI 1504.

A medical expert edit/approval module 1508 may be interposed between thedialog manager 1506 and the medical expert UI 1504. Any automaticallygenerated information might be either sent directly to the user or passthrough the medical expert edit/approval module 1508. In this module,standby physicians or professionals with equivalent training may readauto-responses or questions, and decide whether their responses orquestions are of good enough quality to be directly approved or whetherthey may require edits.

The dialog manager 1506 may be in charge of keeping a state of aconversation between the system and the patient, and routing requests toother components. For example, the dialog manager 1506 may invoke anend-to-end dialog model 1516. The end-to-end dialog model 1516 may be aDeep Learning language model that uses a model pre-trained on a generalcorpuses of text (e.g., Wikipedia), and may be then fine-tuned onmedical conversations between doctors and patients. This technique maybe referred to as transfer learning since patterns learned on a giventask or training corpus are transferred to a similar task. The model maybe learned using a regularized long short-term memory network (LSTM).See e.g., Stephen Merity et al., “Regularizing and Optimizing LSTMLanguage Models,” International Conference on Learning Representations,2018. In particular, the Universal Language Model Fine-tuning for TextClassification (UMLFIT) implementation may be used. See e.g., Howard andRuder, “Universal Language Model Fine-tuning for Text Classification,”Proceedings of the 56th Annual Meeting of the Association forComputational Linguistics, vol. 1 (July 2018). The model may be able toengage with patients in general conversation as well as accuratelyengage in conversations on topics that are common in the training set.However, it may lack an overlay of medical semantics and causalreasoning, and may have no knowledge safeguards. Such a model may beintended to respond to simple queries and determine which more detailedmodel in the system best suits the patient's goals and intent.

A next question module 1514 may be in charge of finding the optimal bestquestion to ask the patient given the current state of the dialog, and,particularly, medically relevant information that is known at a givenpoint of the dialog, as described above.

With input from the patient, the dialog manager 1506 may call an intentclassification module 1518, and, depending on its response, it maydecide which of the following modules described below to call up next.The intent classification module 1518 may detect whether the patient isseeking a diagnosis, or a treatment, or other help. In an embodiment,the intent classification module 1518 may be based on performing medicalentity recognition, using the medical entity recognition module 1524, torecognize words related to either diagnosis or treatment (e.g. symptoms,or medications). In another embodiment, the intent classification module1518 may be a supervised machine learning algorithm trained oninteractions that have been labeled as “diagnosis”, “treatment”, or“other”.

A diagnosis recommendation module 1512 may provide a differentialdiagnosis given what is known about the patient at a given point duringthe dialog. The diagnosis recommendation module 1512 may use a diagnosisalgorithm 1522, an example of which is described above.

A treatment recommendation module 1510 may provide a ranked list ofpotential treatments given what is known about the patient at a givenpoint during the dialog. The treatment recommendation module 1510 mayuse the diagnosis algorithms and then map the differential diagnosis toknown treatments for a given diagnosis using a diagnosis to treatmentmapping 1520.

At this point it should be noted that a medical decision support systemin accordance with the present disclosure as described above may involvethe processing of input data and the generation of output data to someextent. This input data processing and output data generation may beimplemented in hardware or software. For example, specific electroniccomponents may be employed in a computer server or similar or relatedcircuitry for implementing the functions associated with a medicaldecision support system in accordance with the present disclosure asdescribed above. Alternatively, one or more processors operating inaccordance with instructions may implement the functions associated witha medical decision support system in accordance with the presentdisclosure as described above. If such is the case, it is within thescope of the present disclosure that such instructions may be stored onone or more non-transitory processor readable storage media (e.g., amagnetic disk or other storage medium), or transmitted to one or moreprocessors via one or more signals embodied in one or more carrierwaves.

The present disclosure is not to be limited in scope by the specificembodiments described herein. Indeed, other various embodiments of andmodifications to the present disclosure, in addition to those describedherein, will be apparent to those of ordinary skill in the art from theforegoing description and accompanying drawings. Thus, such otherembodiments and modifications are intended to fall within the scope ofthe present disclosure. Further, although the present disclosure hasbeen described herein in the context of at least one particularimplementation in at least one particular environment for at least oneparticular purpose, those of ordinary skill in the art will recognizethat its usefulness is not limited thereto and that the presentdisclosure may be beneficially implemented in any number of environmentsfor any number of purposes. Accordingly, the claims set forth belowshould be construed in view of the full breadth and spirit of thepresent disclosure as described herein.

What is claimed is:
 1. A computer system that applies machine learningmodeling to a healthcare-related input of a patient, comprising: (a) aconversational module configured to carry out an automated conversationwith a patient that elicits the healthcare-related input from thepatient; and (b) a diagnostic reasoning module that applies a machinelearning model to at least a portion of the healthcare-related input todetermine at least one diagnosis or differential diagnosis of thepatient or course of action for the patient.
 2. The computer system ofclaim 1, further comprising a knowledge base that is arranged based onone or more ontological relationships of medical terms and wherein themachine learning model receives an output from the knowledge base thatcomprises a relationship between at least a portion of thehealthcare-related input to a potential differential diagnosis or apotential course of action.
 3. The computer system of claim 2, whereinthe knowledge base is dynamically updated when no relationship exists inthe knowledge base between the at least the portion of thehealthcare-related input to the potential differential diagnosis or thepotential course of action.
 4. The computer system of claim 1, whereinthe computer system is configured to receive multimodal input as part ofthe conversation.
 5. The computer system of claim 4, wherein themultimodal input comprises one or more of written input, spoken input,non-speech audio input, static image input, and video input.
 6. Thecomputer system of claim 1, wherein natural language processing isapplied to at least a portion of the healthcare-related input that isunstructured in order to structure the at least the portion of thehealthcare-related input.
 7. A computer system that applies machinelearning modeling to a healthcare-related input of a patient, thecomputer system comprising: (a) a patient-interface module configured toreceive the healthcare-related input from the patient via auser-interface; and (b) a conversational module configured to: (i) applya machine learning model, that models text, to the healthcare-relatedinput; and (ii) determine, using the machine learning model, one or morewords or sentences to provide to the patient to create at least aportion of a computer-generated conversation with the patient thatrelates to or includes the healthcare-related input or a portionthereof.
 8. The computer system of claim 7, further comprising (c) adiagnostic module configured to determine a diagnosis or a differentialdiagnosis of the patient based on the at least the portion of thecomputer-generated conversation with the patient.
 9. The computer systemof claim 8, wherein the diagnostic module determines the diagnosis byapplying a machine learning model to the healthcare-related input. 10.The computer system of claim 8, comprising a knowledge base that isarranged based on one or more ontological relationships of medicalterms, and wherein the healthcare-related input is applied by thecomputer system to the knowledge base to determine at least onerelationship between data in the knowledge base and at least a portionof the healthcare-related input.
 11. The computer system of claim 10,wherein the diagnostic module receives an output from the knowledgebase, based on the healthcare-related input, that comprises the at leastone relationship between the data in the knowledge base and the at leastthe portion of the healthcare-related input.
 12. The computer system ofclaim 10, wherein the knowledge base is dynamically updated when norelationship exists between the data in the knowledge base and the atleast the portion of the healthcare-related input.
 13. The computersystem of claim 7, wherein the patient interface module is configured toreceive multimodal input as the healthcare-related input.
 14. Thecomputer system of claim 13, wherein the multimodal input comprises oneor more of written input, spoken input, non-spoken audio input, staticimage input, and video input.
 15. The computer system of claim 7,wherein natural language processing is applied to at least a portion ofthe healthcare-related input that is unstructured in order to structurethe at least the portion of the healthcare-related input.
 16. Thecomputer system of claim 7, wherein the one or more words or sentencesis determined by the conversational module to elicit input types thatwill lead to a final disposition with respect to the patient using afewest amount words or sentences.
 17. The computer system of claim 16,wherein the final disposition with respect to the patient comprises adiagnosis of a medical condition of the patient or a course of action.18. The computer system of claim 16, wherein the final dispositioncomprises connecting the patient with a healthcare provider.
 19. Thecomputer system of claim 16, wherein the final disposition comprises anautomated task carried out by the computer system comprising issuing orrenewing a prescription or providing a referral.
 20. The computer systemof claim 7, wherein the computer system creates a profile for thepatient based on one or more of an electronic medical record and aprevious use of the computer system by the patient.
 21. A non-transitorycomputer readable medium including software configured to cause at leastone processor to: (a) receive an initial input from a patient comprisingmedical information of the patient in a natural language format; and (b)determine, using a conversational module of the software, one or moreresponses to the initial input to provide to the patient that willelicit subsequent input from the patient, related to the medicalinformation, that is in a structured format.
 22. The non-transitorycomputer readable medium of claim 21, wherein the software is furtherconfigured to cause the at least one processor to utilize a knowledgebase comprising relationships between medical terms to identify one ormore relationships between the initial input and one or more medicalterms.
 23. The non-transitory computer readable medium of claim 22,wherein the one or more responses to the initial input are determinedbased on the one or more relationships that are identified.
 24. Thenon-transitory computer readable medium of claim 22, wherein the naturallanguage format represents an absence of the one or more relationshipsbetween the initial input and the one or more medical terms.
 25. Thenon-transitory computer readable medium of claim 22, wherein thesoftware is further configured to cause the at least one processor toapply a machine learning model to an output of the knowledge base todetermine the one or more responses.
 26. The non-transitory computerreadable medium of claim 22, wherein the conversational module appliesnatural language processing to the input.
 27. The non-transitorycomputer readable medium of claim 22, wherein the non-transitorycomputer readable medium is configured to receive multimodal input asthe initial input.
 28. The non-transitory computer readable medium ofclaim 27, wherein the multimodal input comprises one or more of writteninput, spoken input, non-spoken audio input, static image input, andvideo input.